A wide variety of activities, interactions and transactions are conducted via communication between computers over a distributed data network such as the Internet. FIG. 2 shows a representative distributed data processing environment where such communication occurs. A number of different computers 150, 210 (or multi-computer data processing centers 220) are all connected to a “network of networks” often illustrated as a cloud 230. Each computer has an address (usually but not invariably unique) and all the computers and network devices (e.g. routers 221, gateways, modems 215 and switches) cooperate to accomplish the low-level goal of delivering data from one endpoint to another, while various pairs of computers cooperate at a higher level to accomplish other ends. Thus, a program executing at any computer is likely to be able to communicate with another program executing at a different computer, although it is appreciated that such communication depends on the machines being capable of (and instructed to) participate in higher-level communication protocols, and to do so at the same time. For example, a web browser 255 at a client computer 150 may be able to communicate with a web server 260 at a computer operated by bank 120 to retrieve account transaction and balance information for display to a user 160.
Many intra-computer interactions are initiated by a user (e.g., by clicking a hyperlink or pressing “play” on a streaming-media receiver), but a significant fraction occur automatically (e.g., on a set temporal schedule), without any human involvement. For many interactions, the difference is immaterial, but some protocols have a security or authentication component, where one side or the other sends sensitive information such as a username, password, or account number. When such sensitive information is needed in the course of an automatically-initiated transaction, the information must be stored (essentially) in unprotected form (i.e., in plaintext). (Of course, the sensitive information may be encrypted, but the automatic process must then have the password to decrypt it, so an attacker need only refocus its attentions slightly. Or, if the service provider takes on the burden of protecting the sensitive information itself, by using hardware encryption or a password entered by one of its employees, then the security of the system depends on the trustworthiness of the service provider and its employees.) By way of contrast, when a person initiates his own transactions, the system can obtain the password interactively. The sensitive information (or the password to access the sensitive information) need not be stored on the computer. It is still possible for the password to be stolen, but an attacker's window of opportunity is reduced. If the sensitive information (and/or the password to the sensitive information) is stored somewhere that it can be accessed automatically, then an attacker can get the information whenever he has the opportunity to do so, and can analyze or decrypt it at his leisure. Also, in the latter situation, the attacker's acquisition of the data is often less likely to be noticed timely, so the passwords or other stolen information may remain valid for a longer time.
The foregoing problems are magnified when an automatic computer service aggregates periodic, password-requiring activities for a number of different users. For example, a financial status monitoring service that accepts bank passwords from many users, and then checks those users' accounts regularly to prepare aggregate reports, becomes a much more attractive target for attackers since a successful attack may yield hundreds or thousands of security credentials. Procedures and protocols that improve the attack resistance of automatic credential-using activities may be of significant value for many computer services.